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Summary 

The  paper  describes  the  prototype  integration, 
on  the  Italian  Air  Force  AM-X  aircraft,  of  the 
Thomson  Convertible  Laser  Designation  Pod. 
The  integration  was  conducted  within  the 
Italian  Air  Force  Official  Test  Centre,  and  the 
process  adopted  was  devised  to  produce  a 
quick,  low-cost,  and  low-risk  sub-system 
integration.  Software  had  the  greatest  part  in 
the  project,  and  software-engineering  methods 
have  been  used  to  support  the  effort. 

This  integration  is  a good  example  of  how  a 
careful  use  of  existing  assets  and  experiences, 
together  with  the  application  of  advanced 
software  engineering  techniques,  can  improve 
the  effectiveness  of  an  aircraft,  keeping  it  up 
with  the  evolving  needs.  The  integration  is 
now  being  used  as  baseline  by  the  aircraft 
manufacturer,  thus  reducing  costs  and  times 
for  the  Italian  Air  Force. 

Introduction 

It  is  widely  accepted  that  the  key  point  in 
keeping  up-to-date  modem  combat  aircraft  is 
no  longer  the  airframe  but  the  mission  system. 
The  airframes  have  a life  that  easily  exceeds 
twenty  years,  while  the  mission  systems 
rapidly  become  obsolete  with  respect  to  the 
ever-advancing  state-of-the-art  of  the 
electronics  and  computers  (Figure  1).  The 
“mid-life  update”  is  an  already  well- 
established  term  indicating  a set  of  upgrades 
ranging  from  structural  life  extension  to  new 
radar,  communication  systems,  navigation 
sensors,  cockpit  instruments,  weapons.  They 
are  extensive  and  expensive  processes,  whose 


aim  is  twofold:  substantial  savings  with  respect 
to  new  designs  (also  due  to  simpler 
procurement  processes),  and  aircraft  with  new 
or  greatly  enhanced  capabilities.  However,  the 
availability  of  standard-interfaced,  off-the- 
shelves  sensors  and  the  need  of  answering  to 
the  evolution  of  threats  and  tasks,  pose  the  air 
forces  with  the  problem  to  modify  the  mission 
systems  more  frequently.  In  addition,  the  key 
role  played  by  the  software  in  nowadays 
airborne  systems  offers  new  opportunities  to 
execute  upgrades  of  the  combat  aircraft 
without  having  large  industrial  facilities  like 
those  requested  to  modify  or  upgrade  the 
airframes. 

Development  and  In-Service  Periods 
(years) 


Figure  1 - Examples  of  aircraft  operational  life 

As  final  users,  the  air  forces  are  the  best 
candidate  to  identify  and  analyse  the  new 
requirements  to  be  implemented.  Many  of 
them  have  therefore  developed  in-house 
capability  to  study  or  to  modify  the  software 
running  on  their  aircraft.  The  Italian  Air  Force 
(IAF)  is  currently  introducing  into  service  the 
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final  version  of  its  AM-X  light  attack  aircraft. 
In  order  to  improve  its  capabilities,  IAF 
considered  various  retrofits  to  the  mission 
system,  and,  specifically,  the  integration  of  a 
laser  designation  pod,  to  provide  the  aircraft 
with  a laser  guided  bomb  self  designation 
capability. 

We  describe  the  software  aspects  of  the 
integration,  by  focusing  mainly  on  the 
requirements  engineering  activities.  The 
hardware  modifications  were  in  fact  limited  to 
those  strictly  needed  to  connect  the  laser  pod 
to  the  AM-X  avionics  system  RIG  (i.e.,  power 
lines,  data  cables,  and  control  switches). 

In  the  early  stage  of  the  requirements 
engineering  activities,  aspects  such  as  the  final 
system  goals,  the  feasible  alternatives,  the 
different  and  often  clashing  interests  of  the 
various  people  affected  by  the  system  (pilots, 
developers,  etc.)  are  addressed.  The  objective 
of  the  late  phase  requirements  engineering 
activities  is  to  produce  a requirement 
document  that  would  specify  and  constrain  the 
final  system,  therefore  suitable  to  be  adopted 
in  a contractual  setting.  We  used  a rapid 
prototyping  technique , by  exploiting  an 
evolutionary  prototype  to  elicit  and  validate 
system  requirements.  The  analysis  and  the 
validation  of  the  requirements  drove  the 
evolution  of  the  project  into  an  incremental 
method , where  the  use  of  the  prototype  caused 
a continuous  evolution  of  the  requirements 
themselves.  We  dedicated  great  attention  to  the 
requirements  capture  and  validation,  by 
carefully  assessing  their  relevance  both  for  the 
operative  situations  and  for  the 
implementation.  As  final  result,  the  prototype 
has  become  an  “animated”  and  “validated” 
requirements  document,  yet  a fundamental 
component  of  the  final  system. 

The  following  part  of  the  present  paper  is 
organised  as  follows.  Section  2 briefly 
introduces  the  integration  problem.  Section  3 
provides  an  overview  of  the  proposed  solution 
approach,  and  of  its  rationale  Section  4 
discusses  the  project  results,  by  providing  both 
qualitative  and  quantitative  insights.  Finally, 
Section  5 concludes  the  description  of  the 
work,  by  summarising  the  benefits  of  the 
adopted  approach. 

Integration  Problem  Overview 

The  Aircraft  The  AM-X  has  been  developed 
by  an  Italian-Brazilian  joint  effort  to  provide 
both  air  forces  with  an  aircraft  capable  to 


deliver  a medium  load  out  of  short  or  semi- 
prepared  airfield,  at  a moderate  distance  and 
high  subsonic  speed.  Design  studies  began  in 
1977,  and  IAF  took  delivery  of  its  first  AM-X 
in  October  1989.  The  basic  AM-X 
performance  and  weapons  data  are  published 
in  [1];  only  some  of  them  have  been  reported 
in  Table  1. 


Manufacturer 

Alenia  (Italy) 
Aermacchi  (Italy) 
Embraer  (Brasil) 

Wing  Span 

9.9  mt 

Length 

13  mt 

Height 

4.5  mt 

Wing  Surface 

21  mt2 

Engine 

Turbofan 
(without  a/b) 

Max.  Speed 

subsonic 

Max.  Height 

> 12000  mt 

Max.  Range  (ferry) 

> 3000  Km 

Table  1 - AM-X  Performance  Data 


The  AM-X  mission  system  is  a typical  first 
generation  1553-bus  (Mil-bus)  design,  built 
around  a digital  mission  computer,  which  acts 
also  as  bus  controller  (Bus  Controller/Main 
Computer  - BC/MC).  The  mission  subsystems 
and  sensors  are  connected  as  remote  terminals. 

The  Man-Machine  Interface  (MMI)  of  the 
mission  system  is  designed  around  two  main 
displays:  a “Multifunctional  Head  Down 
Display”  (HDD),  with  configurable  function 
keys,  and  a “Head  Up  Display”  (HUD).  The 
HDD  performs  also  part  of  the  route  and 
display  computations,  thus  leaving  more 
computational  power  available  on  the  BC/MC. 

The  Laser  Designation  Pod.  The  laser 
designation  pod  selected  for  the  AM-X  is  the 
Thomson  Convertible  Laser  Designation  Pod 
(CLDP)  [2],  already  operative  on  the  IAF 
TORNADO  IDS,  on  the  French  Air  Force 
JAGUAR  and  MIRAGE  2000. 


Main  Body 


Forward  Section 

crcrrv  Camera)  Ro(l  section  Fluid  Cooling 

Unit 

Figure  2 - The  Convertible  Laser  Designation 
Pod  (CLDP) 
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The  CLDP  (Figure  2)  allows  the  aircraft  crew 
to: 

• visually  acquire  an  on-ground  target  (the 
CLDP  can  be  equipped  with  either  a TV 
or  Thermal  camera,  i.e.  the  Convertible 
capability); 

• track  the  target  (various  internal 
algorithms  are  available); 

• measure  the  target/aircraft  distance; 

• illuminate  the  target  for  subsequent 
weapon  guidance. 

Integrate  the  CLDP  onto  the  AM-X.  Despite 
the  wide  diffusion  of  similar  systems,  the 
integration  of  the  CLDP  on  the  AM-X  posed 
upon  us  a new  challenge. 

The  initial  pre-feasibility  study  [3]  (that 
prompted  the  acquisition  of  a prototype  CLPD 
for  the  AM-X)  had  only  defined  the  guidelines 
for  the  integration:  the  CLDP  had  to  be  used  as 
a targeting  sensor  for  the  precision  delivery  of 
Laser  Guided  Bombs  (LGB),  and  as  a 
navigation  sensor.  The  CLDP  prototype 
integration  project  was  therefore  set  off  as  a 
low-budget  short-term  activity  aiming  at  (1) 
fully  investigating  the  feasibility  of  equipping 
the  AM-X  with  the  CLDP,  and  (2)  identifying 
an  economical  and  low-risk  integration 
solution.  This  kind  of  activities  shows  grey  (or 
black)  areas  that  generate  risks  for  the  project. 
Some  risks  are  typical  of  the  integration 
projects,  some  other  are  particular  of  this 
specific  case,  as  discussed  in  the  following. 

Complexity  of  the  solution  space. 

Finding  a solution  to  the  integration  problem 
means  to  define  a complete  and  consistent  set 
of  requirements  that  the  new  system  (i.e.  the 
aircraft  equipped  with  the  CLDP)  has  to 
satisfy.  Only  a minor  set  of  these  requirements 
concern  technical  (functional)  aspects  of  the 
integration  (e.g.  the  data  the  CLDP  has  to 
provide  as  navigation  sensor);  most  of  them 
are  related  to  non-functional  aspects.  These 
regards  both  human  factors,  such  as  pilot 
workload,  pilot  performance,  and  situation 
awareness,  and  system  quality  attributes,  such 
as  safety,  reliability,  time  and  cost.  In 
comparison  with  functional  requirements,  non- 
functional requirements  are  highly  subjective 
(e.g.  test  pilots  and  front  line  pilots  can  have  a 
different  perception  of  the  same  problem), 
strictly  related  to  the  particular  context,  and 
more  difficult  to  be  discovered,  stated  and 
validated,  without  “interacting”  with  the  final 
system.  This  increases  the  complexity  of  the 
solution  space,  introduces  a certain  degree  of 


instability  in  the  requirements,  and  makes 
difficult  to  compare  different  alternatives. 
However,  being  mistakes  made  at  the 
requirements  definition  stage  extremely 
difficult  (and  expensive)  to  recover  during  the 
subsequent  system  development,  it  is  crucial, 
for  the  requirements  engineering  process,  to  be 
able  to  cope  with  such  difficulties. 

Complexity  of  the  target  platform 
Although  the  AM-X  mission  system  can  be 
classified  as  a traditional  one,  it  presents  some 
elements  of  complexity.  With  regards  to  the 
stored  data  and  to  the  functions  offered  to  the 
pilot,  it  can  in  fact  be  defined  as  a distributed 
system.  In  other  words,  many  of  the  functions 
in  the  mission  system  are  performed  via  a co- 
operation of  two  or  more  subsystems.  As  a 
consequence,  modifying  or  enhancing  such 
functions  requires  operating  on  different 
equipment,  which  may  adopt  different 
hardware  and  software  solutions  (e.g.  the  used 
programming  languages  go  from  assembly,  to 
Fortran,  to  Ada),  requiring  a broad  range  of 
skills  not  usually  available  in  the  same 
personnel.  Moreover,  equipment  are  often 
produced  and  maintained  by  different 
companies,  so  that  the  Air  Force  is  faced  with 
different  levels  of  visibility,  procurement 
processes  and  schedules. 

Novelties  of  the  Project 
The  basics  of  the  Laser  Guided  Bombs 
operations  were  well  known,  thanks  to  the 
Tornado  experience;  but  IAF  specialists  had 
still  a limited  inside  knowledge  of  the  AM-X 
mission  system.  In  addition,  it  was  the  first 
example  within  the  IAF  of  use  of  the  CLDP  on 
a single-seater  aircraft. 

Project  Organisation 

In  order  to  reduce  the  associate  risks,  and  to  be 
compliant,  at  the  same  time,  with  the  low- 
budget  and  short-term  constraints  posed  on  the 
project,  it  has  been  organised  following  some 
simple  guidelines,  that  is: 

• minimise  modifications  to  the  AM-X 
avionics  system; 

• exploit  internal  IAF  resources  and 
capabilities,  i.e.  personnel  (test  pilots  and 
engineers,  technicians)  and  equipment 
(low-cost  avionics  simulators  and 
computers). 

• re-use  of  previous  experiences,  both  in 
terms  of  lesson  learned  and  products.  In 
particular,  various  projects  regarding  both 
the  Tornado  (among  which  the  CLDP 
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integration),  and  the  Italian  Navy  EH-101  fact  perform  any  kind  of  control  on  the  CLDP, 

helicopter1  mission  systems  were  carefully  but  redirects  the  CLDP  data  to/from  the  HDD, 

analysed,  to  identify  requirements,  and  provides  the  HDD  with  basic  data  about 

algorithms,  and  software  suitable  to  be  the  mission  system  (navigation,  attack),  and 

reused  and  errors  to  be  avoided.  the  aircraft  (attitude,  position,  speed). 


In  practical  terms,  this  has  led  us  to  make 
precise  choices  regarding  the  product  to 
develop,  the  process  to  apply,  and  the  team  to 
employ. 

The  Product.  The  integration  of  the  CLDP  to 
the  AM-X  avionics  system  asked  both  for  new 
software  and  hardware.  The  new  hardware  was 
maintained  to  the  absolute  minimum:  the 
on/off  and  laser  safe/armed  switches,  the  Mil- 
bus  and  the  electrical  signal/power  lines.  These 
new  links  were  dictated  by  the  CLDP,  that  was 
an  off-the-shelves  item. 

We  had  more  freedom  for  the  design  of  the 
software  architecture  and  for  the  allocation  of 
the  corresponding  components  onto  the 
various  computers  of  the  avionics  system. 

We  decided  to  concentrate  in  the  HDD  the 
software  to  control  the  CLDP,  to  minimise  the 
number  of  equipment  to  be  updated  and  to 
exploit  the  characteristics  of  the  HDD  itself. 
The  HDD  was  in  fact  the  newest  equipment  of 
the  mission  system,  its  Motorola  processor 
provided  the  needed  growth  capability,  and  its 
software  was  written  in  Ada,  the  most 
advanced  among  the  programming  languages 
used  on  the  aircraft.  In  addition,  the  HDD  was 
ready  to  receive  and  display  the  images 
generated  by  the  CLDP, 

The  software  modifications  to  the  BC/MC 
were  instead  limited  to  those  strictly  necessary 
to  introduce  some  Mil-bus  messages  and  to 
extend  the  navigation  and  attack  functions,  to 
employ  the  CLDP.  For  example,  by  enabling 
the  BC/MC  software  to  receive  and  use  also 
data  incoming  from  the  CLDP,  the  correction 
of  the  position  of  the  aircraft  (i.e.  present 
position  fixing)  can  now  be  performed  also 
using  the  CLDP  (more  versatile  than  the 
forward-looking  radar  or  the  simple  on-top 
method).  The  new  Mil-bus  messages  have 
been  added  to  allow  the  CLDP  to  exchange 
data  with  the  HDD.  The  BC/MC  does  not  in 


1 The  EH-101,  produced  by  UK  WESTLAND  and 
IT  AGUSTA  is  a joint  effort  to  produce  a versatile 
multi-role  platform  for  tactical  transport,  Anti- 
Submarine  Warfare,  Search  And  Rescue,  and 
civilian  transport. 


Figure  3 - Example  HDD  page  for  the  CLDP 

The  HDD  software  has  received  only 
extensions.  In  particular:  to  handle  the  new 
Mil-bus  messages  [4];  to  implement  the 
required  CLDP  command  and  real-time 
control  loop;  to  manage  the  CLDP  pilot 
interface.  The  HDD  software  implements  the 
pilot  interface  as  a collection  of  cross-linked 
menu  pages.  By  navigating  through  these 
pages,  the  pilot  can  access  the  various 
operations  available:  for  example,  synthetic 
maps,  status  of  the  equipment,  and  so  on.  For 
our  purpose,  the  software  has  been  extended  to 
add  some  dedicated  pages  to  control  the 
CLDP.  In  other  words,  a new  menu  page  has 
been  devised  for  each  main  class  of  CLDP 
functionality.  Specifically,  it  has  been  added  a 
dedicated  page  to  access/perform  the  various 
navigation  operations  (present  position  fixing, 
on-ground  point  acquisition),  attack 
operations,  testing  operations,  and  so  on.  As 
example,  in  Figure  3 it  is  depicted  in  a 
simplified  way  the  HDD  page  through  which 
the  pilot  can  perform  a “present  position 
fixing”  employing  the  CLDP.  By  using  this 
page,  the  pilot  can  select  the  fix  point  (FIXPT 
key  on  Figure  3),  disable/enable  the  firing  of 
the  laser  (LFIRE),  read  the  position  correction 
values  (as  range  and  bearing),  and  ACCEPT  or 
EXIT  the  procedure.  The  Ada  software 
architecture  has  been  designed  to  obtain  a high 
independence  between  the  functions  written  to 
control  the  CLDP,  and  the  functions 
implementing  the  interface.  This  allowed  us  to 
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produce  stable  software  for  the  command  and 
control,  yet  having  the  possibility  to  change 
the  interface  without  impacting  onto  the  deep 
(and  more  delicate)  algorithms  of  the  CLDP 
control.  Whereas  the  definition  of  the  final 
interface  structure  was  obtained  by 
continuously  refining  it  with  the  pilot,  the 
internal  management  of  the  CLDP  and  the 
used  algorithms  were  an  exclusive  subject  of 
discussion  of  the  engineers.  They  worked 


using  the  Tornado  experience  and  evolved 
them  with  a lower  number  of  refinement 
cycles. 

To  conclude,  in  Figure  4 a simplified  view  of 
the  chosen  integration  architecture  is  pictured. 
Here  it  is  shown  also  the  CLDP  hardware 
control  panel  which  provides,  for  example,  the 
on/off  and  laser  safe/armed  switches. 


Discrete 

Signal 


Figure  4 - Simplified  view  of  the  integration  architecture 


The  Project  Team.  The  project  Team  was 
organised  in  order  to  reduce  as  much  as 
possible  the  number  of  involved  people  (and 
the  corresponding  co-ordination  problems), 
and  to  exploit  the  available  skills.  Then,  to 
increment  the  degree  of  concurrency  between 
the  different  tasks  to  be  performed,  the  project 
team  has  been  divided  up  into  3 different  sub- 
groups, with  specific  competencies, 
responsibilities  and  workload: 

Software  Development  Team , with  the  task  of 
managing  the  whole  project  and  develop  the 
necessary  software,  composed  of  2 software 
engineers  and  2 technicians.  In  particular,  the 
group  members  worked  together  for  the 
requirements,  while  each  of  them  was 
dedicated  to  the  single  aspects  of  the  ADA 
code,  the  Fortran  code,  the  Assembler  code 
and  the  operating  systems. 

Hardware  Support  Team , with  the  task  of 
performing  the  CLDP  hardware  integration 


onto  the  AM-X  avionics  system  and  taking 
care  of  its  maintenance,  composed  of  2 
technicians; 

User  Group , with  the  task  of  collaborating  the 
requirements  elicitation  and  validation  phases, 
composed  of  a test  pilot  and  a Tornado  test 
navigator.  Both  of  them  had  specific 
experience  with  LGB  operations,  and  were 
supported  by  front  line  pilots. 

The  Development  Process.  Two  paradigms 
usually  adopted  within  software  engineering  to 
reduce  and  manage  risks  associated  with 
requirements  instability  and  complexity  have 
been  adopted  and  customised:  rapid 

prototyping  and  incremental  development  [5]. 

The  classical  software  development  approach 
(the  waterfall  model)  is  based  upon  a series  of 
sequential  stages  that  goes  from  requirements 
analysis,  through  coding  and  testing,  to  the 
system  delivery.  Here,  it  is  assumed  that  most 
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of  the  requirements  can  be  defined  at  the  outset 
of  the  project,  whereas  it  is  well  recognised 
that  requirements  instability  could  easily  lead 
to  critical  cost  and  schedule  overruns. 

Rapid  prototyping  is  method  a in  which  the 
exact  opposite  of  the  traditional  software 
development  approach  is  held  true:  time  and 
resources  are  fixed,  as  far  as  possible,  and  the 
requirements  are  allowed  to  change.  It  is 
therefore  suitable  for  all  those  cases  in  which 
the  requirements  cannot  be  exactly  defined  at 
the  beginning  of  the  development.  For 
example,  when  the  stakeholders  do  not  have  a 
clear  idea  of  the  system  to  be  developed,  but 
this  will  mature  over  time,  or  when  different 
solutions  seem  to  be  equally  valid  and  a deeper 
analysis  appears  to  be  necessary.  To  achieve 
its  goals,  rapid  prototyping  employs  user- 
centred  product  prototypes,  and  requires  a 
close  collaboration  between  users  and 
developers.  Software  prototypes  come  in 
different  form,  including  throwaway 
prototypes,  quick-and-dirty  prototypes,  and 
evolutionary  prototypes,  that  is  prototypes  that 
evolve  in  the  final  system.  The  common  idea  is 


to  allow  the  developers  to  rapidly  construct 
primitive  versions  of  the  software  system  that 
the  users  can  interact  with  and  evaluate.  The 
obtained  feedback  is  incorporated  to  correct, 
refine,  and  enrich  the  emerging  system 
properties. 

In  order  to  deal  with  the  previously  described 
complexity  of  the  solution  space,  a rapid 
prototyping  techniques  has  been  adopted  to 
perform  our  integration  study.  In  particular, 
rather  than  developing  the  CLDP  control 
software  directly  on  the  HDD,  an  evolutionary 
prototype  of  such  software  has  been 
developed.  This  software  model  (thereafter 
referred  to  as  Virtual  HDD)  gave  us  a powerful 
tool  for  the  requirements  analysis  at  an  early 
stage,  that  was  usable  throughout  the  full  life 
cycle  of  the  software  (evolutionary  prototype). 
The  virtual  HDD  has  in  fact  allowed  us  to 
enrich  our  avionics  RIG  with  the  CLDP,  and 
then  use  the  RIG  analyse  the  CLDP  operating 
procedures  with  the  members  of  the  User 
Group. 


(i 


Software  Testing  Station 


[ Ethernet 

i I 


Software  Development  Stations 


Figure  5:  Architecture  of  the  Avionics  RIG 


A simplified  scheme  of  the  architecture  of  the 
AM-X  Avionics  System  RIG  (ASR)  used 
through  the  integration  study  is  illustrated  in 
Figure  5.  Apart  from  the  Software 
Development  Stations  and  the  Software 
Testing  Station,  used  to  modify  the  airborne 
software  and  test  it  directly  on  the  BC/MC,  the 
ASR  consists  of  a mixture  of  real  and 
simulated  equipment.  For  example,  while  all 
the  main  sensors  are  simulated  (Inertial 


Navigation  System,  Air  Data  Computer, 
Tacan,  etc.),  a real  CLDP  is  used,  together 
with  real  units  associated  with  the  AM-X 
mission  system  MMI  (HDD,  HUD,  switches 
and  selectors,  Pilot  Stick  and  Throttle).  The 
MMI  allows  a pilot  to  form  part  of  the  overall 
rig,  so  that  the  effects  of  the  proposed  new 
weapon  system  on  pilot  performance  can  be 
determined.  It  is  worth  noting  that  in  order  to 
reduce  the  costs  associated  with  ASR 
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development  and  maintenance,  the  ASR  has 
been  designed  to  provide  only  the  capabilities 
strictly  necessary  to  perform  the  integration 
study.  The  absence  of  more  complex  features, 
as,  for  example,  a wrap-around  display  to 
represent  the  external  world,  has  been 
overcome  by  employing  especially  trained 
personnel. 

The  simulated  subsystems  are  realised  using  a 
high-level  testing  tool,  i.e.  the  AIDASS,  by 
ALENIA.  It  consists  of  a set  of  real  time  VAX 
computers  inter-linked  via  a VME  bus,  and 
equipped  with  the  interfaces  necessary  to  be 
connected  the  AM-X  avionics  system  (Mil- 
bus,  discrete  and  analogue  signals).  Both  the 
aircraft  simulator  and  the  set  of  sensor 
simulators  have  been  developed  within  the  IAF 
Operational  Test  Centre,  by  partially 
customising  software  created  for  other 
projects.  As  the  other  simulated  equipment, 
also  the  Virtual  HDD  was  implemented  on  the 
testing  tool  AIDASS.  This  not  only  gave  us  the 
possibility  of  using  the  Ada  programming 
language  (the  same  adopted  in  the  real  HDD) 
that,  combined  with  an  ad-hoc  design,  allowed 
us  to  obtain  a software  package  immediately 
portable  on  the  real  HDD,  but  also  of 
employing  an  advanced  environment  for 
software  debugging. 


to  deal  with  unstable  requirements,  it  is 
difficult  to  apply  on  big  projects,  and  can 
easily  lead  to  an  explosion  of  project 
complexity,  and  associated  risks,  whenever 
requirements  instability  is  not  confined  to  a 
specific  area.  For  such  a purpose,  an 
incremental  development  approach  has  been 
adopted  in  conjunction.  In  other  words,  in 
order  to  reduce  and  manage  project 
complexity,  the  initial  “unstable”  set  of 
requirements  have  been  divided  up  into  three 
sub-sets,  that  is: 

• the  sub-set  A,  regarding  the  CLDP  basic 
control  functions  (e.g.  test  functions, 
CLDP  pointing,  etc.),  and  implementing 
the  CLDP  interface  control  document; 

• the  sub-set  B,  regarding  the  integration  of 
the  CLDP  with  the  aircraft  navigation 
functions; 

• the  sub-set  C,  regarding  the  integration  of 
the  CLDP  with  the  aircraft  attack 
functions. 

In  Figure  6 it  is  schematised  the  software 
development  process  adopted  to  perform  the 
integration  study,  especially  devised  to 
combine  the  benefits  provided  by  the  rapid 
prototyping  and  the  incremental  development 
techniques. 


Although  rapid  prototyping  is  a good  solution 


feedback 
(errors,  new 
requirements) 


Requirements 
set  A 


Figure  6:  The  adopted  development  process 
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As  shown  in  Figure  6,  such  a process  is  based 
on  two  main  phases. 

During  the  phase  /,  the  virtual  HDD  was 
developed.  In  particular,  first,  the  Virtual  HDD 
was  built  by  fully  developing  the  sub-set  A of 
the  requirements  (Virtual  HDD  version  A), 
then  by  introducing  the  sub-set  B (to  obtain 
Virtual  HDD  version  B),  and  finally  by 
introducing  the  sub-set  C (to  obtain  the  Virtual 
HDD  version  C).  After  being  developed,  each 
version  was  evaluated  by  employing  the  ASR. 
The  evaluation  was  performed  mainly  by  the 
User  Group,  which  was  involved  in  order  to 
validate,  correct  or  improve  the  requirements 
already  implemented,  and  to  discover  new 
requirements.  Depending  on  the  results  of  this 
evaluation,  more  correction  and  refinement 
loops  occurred.  Only  when  the  version  C of 
the  Virtual  HDD  resulted  to  satisfy  the  users 
needs  (i.e.  the  Virtual  HDD  was  a full 
representation  of  the  desired  final  system),  we 
passed  to  the  phase  2 . Here  the  software 
implementing  the  Virtual  HDD  was  ported  on 
the  real  HDD,  and,  this,  on  its  turn,  was 
evaluated.  As  final  result,  the  modified  HDD 
became  an  “animated”  and  “validated” 
requirements  document,  yet  a fundamental 
component  of  the  final  system. 

Having  defined  the  development  process,  we 
were  able  to  clearly  identify  and  separate  the 
efforts  of  the  various  sub-groups  of  the  Project 
Team,  increasing  the  concurrency  within  the 
different  project  tasks  and  between  this  project 
and  other  projects.  Moreover,  the  HDD 
manufacturer  was  involved  to  modify  the  real 
HDD  only  at  a late  stage,  when  a stable  idea  of 
the  final  system  was  available,  reducing  the 
associated  costs  and  schedule. 

The  described  process  regards  the 
development  of  the  software  for  the  HDD.  Due 
in  fact  to  the  small  amount  of  changes  required 
by  the  software  of  the  BC/MC,  a more 
traditional  approach  was  applied  in  this  case. 
In  particular,  the  BC/MC  software  was 
modified  to  follow  the  evolution  of  the  Virtual 
HDD,  and  to  allow  its  integration  on  the  ASR. 

Project  Results 

Single-Seater  or  Two-Seater?  IAF  opted  for 
the  CLDP  modification  to  be  used  by  the 
single-seater  version  of  the  AM-X.  On  the 
other  hand,  LGBs  are  used  onto  other  single- 


seater  (e.g.  the  French  JAGUAR  2). 

The  presence  of  a single  crewman  faced  us 
with  a set  of  requirements  that  were  not 
present  on  the  Tornado,  where  the  navigator 
can  dedicate  himself  to  the  CLDP  operations. 
We  answered  to  these  requirements  in  two 
steps: 

• a more  careful  construction  of  the 
“Operator  Dialogue”  (i.e.  the  sequence  of 
buttons  to  be  pressed  to  obtain  a function) 
of  the  MMI,  in  order  to  make  the  use  of  the 
CLDP  as  simple  and  straight  as  possible, 
without  reducing  the  number  of  available 
functions; 

• a set  of  facilities  to  lower  the  workload  of 
the  pilot  and  to  enhance  the  safety  of  the 
operation. 

The  MMI  was  implemented  by  using  at  the 
maximum  extent  the  available  HOTAS  (Hands 
On  Throttle  And  Stick)  commands  (e.g.  the 
CLDP  LOS  is  controlled  via  the  same  joystick, 
placed  on  the  throttle,  that  is  already  used  to 
point  the  Radar  Antenna).  Moreover,  to  allow 
the  pilot  to  point  the  CLDP,  looking  either 
inside  or  outside  the  cockpit,  we  used  a cross 
symbol  already  available  on  the  HUD  to  mark 
the  same  spot  looked  at  by  the  CLDP  camera. 

In  order  to  keep  low  the  risks  induced  by  the 
pilot  looking  inside  the  cockpit,  at  the  HDD, 
an  essential  attitude  indicator  is  superimposed 
to  the  CLDP  image,  along  with  alert  messages 
(e.g.  “ROLL  OUT”),  should  some  basic 
aircraft  attitude,  speed  or  terrain  separation 
limit  be  violated.  The  presence  of  the 
automatic  pilot,  and  the  philosophy  of  LGB 
attacks,  that  foresees  medium-to-high-altitude 
attacks  in  a context  of  air-superiority,  also 
support  the  viability  of  the  single-seat  use. 

Nevertheless  the  CLDP  modification  is 
immediately  portable  and  fully  compatible 
with  the  two-seater  version  of  the  AM-X.  The 
two-seater  will  offer  the  advantage  of  a 
dedicated  crewmember  for  the  management  of 
the  laser  pod.  It  will  allow  an  effective  training 
at  low  risk,  and,  also,  “co-operative  attacks” 
(one  illuminator  ship,  more  carrier  ships),  for 
which  a dedicate  crewmember  is  deemed 
essential. 


2 The  JAGUAR  uses  the  same  CLDP  pod.  but  it 
can  deliver  the  AS-30  missile,  with  a greater  stand- 
off range  with  respect  to  the  LGBs  used  by  the  AM- 
X. 
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Quantitative  Insights.  The  final  size  of  the 
produced  software  is  of  9000  Ada  LOC  (Line 
Of  Code)  for  the  HDD,  and  300  Fortran  LOC 
plus  150  Assembly  LOC  for  the  BC/MC.  The 
relative  impact  of  the  modification  with 
respect  to  the  total  software  is  low  (Table  2). 
This  is  a welcome  property,  which  keeps  low 
the  risk  of  introducing  new  defects  and  reduces 
the  work  of  re-evaluating  and  testing  the 
existing  functions. 


Airborne 

Computer 

Modified 

Software 

New 

Software 

BC/MC 

2% 

i% 

HDD 

1% 

15% 

Table  2 - Percentages  of  Modified  and  New 
Software 


On  the  basis  of  the  development  process 
described  in  the  previous  Section,  a more 
detailed  analysis  is  possible. 

The  initial  release  of  the  Virtual  HDD  (version 
A),  consisting  of  about  5500  Ada  LOC,  200 
Fortran  LOC,  and  150  assembly  LOC,  was 
produced  in  about  7 months.  The  personnel 
involved  were,  initially,  only  the  members  of 
the  Software  Development  Team.  Once  the 
confidence  into  the  technical  feasibility  of  the 
project  was  achieved,  the  User  Group  was 
involved  to  deal  with  the  operative 
requirements,  while  the  Hardware  Support 
Group  updated  as  required  the  ASR.  Then  the 
first  period  of  evaluation,  debug,  and  re- 
evaluation  of  the  model  was  performed. 

Having  reached  a stable  version  A,  we  started 
introducing  the  sub-set  B of  the  requirements. 
This  phase  lasted  about  5 months.  Then  we 
started  the  integration  of  the  sub-set  C of 
requirements.  The  phase  ended  after  about  3 
months,  therefore  the  version  C of  the  Virtual 
HDD  (about  10000  LOC,  airborne  code  plus 
some  ancillary  code  for  the  RIG)  was 
produced  in  a 15-month  period. 

The  porting  of  the  Virtual  HDD  version  C onto 
the  real  HDD  was  straight.  The  only  exception 
was  a fine  parameterisation  of  the  code  due  to 
the  different  way  of  numbering  the  bits  within 
a word,  used  on  the  VAX  of  the  virtual  HDD 
and  on  the  Motorola  microprocessor  of  the  real 
HDD.  For  the  porting,  two  people  from  the 
HDD  manufacturer  were  involved,  for  a 
limited  number  of  meetings  and  for  a total  of  6 
days  of  actual  integration.  As  further 
confirmation  of  the  quality  of  the  Virtual 


HDD,  and  of  the  adopted  development 
process,  the  evaluation  on  the  ASR  of  the 
modified  HDD  revealed  only  some  minor 
defects. 

The  effort,  duration  and  size  of  the  project  are 
well  estimated  by  the  Constructive  Cost 
estimation  Model  (COCOMO)  [6],  as 
illustrated  by  Table  3,  where,  for  the  sake  of 
brevity,  only  the  main  results  obtained  by 
applying  such  an  estimation  tool  are  reported. 

The  delay  of  the  project  with  respect  to  the 
schedule  provided  by  the  COCOMO  equations 
(about  5 months)  is  due  mainly  to  pre-emption 
of  personnel  for  other  tasks  (about  3 months), 
and  to  some  bureaucratic  delays  with  the 
partner  industries  (about  1 month).  In  addition, 
the  team  was  smaller  than  the  estimated  one. 


Size 

10,25 

Kilo  delivered  LOC 

Effort 

76,02 

Man-Month 

Schedule 

9,99 

Months 

Average  Team  Size 

7,60 

Persons 

Table  3 - The  COCOMO  Model  applied  to  the 
AM-X  / CLDP  Integration  case 


Costs.  The  costs  of  our  integration  study  are 
low,  mainly  due  to  the  project  having  been  run 
with  in-house  resources  (personnel  and  low- 
cost  RIGs),  and  a small  support  from  the 
partner  industries. 

The  recurrent  costs  are  quite  low,  being  limited 
to  the  reload  of  some  software  packages,  and 
to  the  introduction  of  the  CLDP  on/off  switch, 
power  supply  cables  and  connectors.  The 
CLDP  are  basically  those  already  available  for 
the  Tornado,  so  the  costs  of  the  logistics  can  be 
shared  with  the  other  aircraft. 

Enhancement  of  Capability.  The  need  for 
precision  attacks  from  high  altitude 
dramatically  emerged  in  the  current  scenarios 
of  peace  keeping/enforcing  operations,  where 
“surgical”  attacks  are  needed.  IAF  also  needed 
to  enhance  the  effectiveness  of  each  single 
aircraft,  in  a context  of  a shrinking  budget. 

The  CLDP  is  a viable  answer  to  the  above 
problems,  therefore  the  benefits/costs  ratio  of 
it  should  be  considered  high  just  for  operative 
reasons,  also  without  taking  into  account  the 
economical  advantages  of  our  implementation. 
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Conclusions 

We  described  a prototype  integration  of  a laser 
illumination  pod  onto  the  AM-X  aircraft,  in  the 
context  of  a low-cost,  high-confldence-of- 
success  project. 

Software  can  be  changed  without  large 
industrial  facilities  and  software  upgrades  can 
greately  enhance  an  aircraft  performances.  Our 
solution  was  a software  modification  at  95%, 
and  made  large  use  of  software  engineering 
techniques  to  quickly  obtain  the  desired  results 
at  low  costs.  We  consider  our  experience  as 
positive  and  successful.  The  general  guidelines 
emerging  from  it  are  the  following: 

• consider  using  off-the-shelves  equipment 
and  modification  of  the  software,  to  match 
new  requirements  in  a cheap  a viable  way; 

• exploit  the  capacity  to  blend  legacy  or 
available  systems  and  new  devices  in  the 
path  of  reducing  costs  and  time; 

• use  tight  collaboration  among  industry, 
operating  people  and  engineers  of  the  Air 
Force; 

• employ  small,  committed  groups;  with  a 
clear  and  realistic  scope; 

• be  aware  that  bureaucratic  problems  are 
independent  from  the  complexity  of  the 
technical  problems.  They  are  functions  of 
the  visibility  of  the  project  and  of  the 
number  of  groups  involved; 

• use  simulation  for  assessment  & 
evaluation,  but  use  the  real  software  and 
hardware  for  the  finalisation  of  the  work, 
to  avoid  duplications,  delays  and  costs. 
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